Activity Diagram (act) = one of three ways to express information about system’s dynamic behavior (activity, sequence, state machine), it’s a dynamic view of the system that expresses sequences of behaviors and event occurrences over time. (whereas a structure diagram like BDD, IBD and parametric diagrams show static views that convey no sense of time or change within the system or its environment.
An activity diagram expresses the flow of objects through a behavior with focus on how the objects can be accessed and modified during system operation (time). Though one disadvantage is that it cannot show which structure invokes the actions (this can be shown in sequence diagram). Activity diagrams good as analysis tool when working with stakeholders to define the problem space and specify the required behavior of the system. Generally the first behavior diagram worked with stakeholders, though can be created and used during any point of system life cycle.
Activity
Activity = model element, a behavior, and a namespace like a block or package. It can contain nodes and edges within the model hierarchy. An activity and activity diagram are not synonyms. Diagram of model is only a view of the whole model.
Token Flow
Token flow = abstract concept where tokens are not model elements but imaginary marker running through the activity diagram. Object token – is an instance of matter, energy or data that flows through an activity. There can be multiple flowing through single execution of an activity. Control token used to show which action in an activity is currently enabled at a particular moment during execution.
Action
Action = one kind of node in activity that models a basic unit of functionality – or some form of processing or transformation that will occur during execution. (noted by round cornered rectangle). Name of action should start with unambiguous verb.
An action can also be written in opaque expression, which is composed of language (curly brackets) and body.
Object Node
Object node = node that models the flow of object tokens through an activity (object token = data, energy, matter). An action can lead to object node which holds the object tokens.
Pin = specialized kind of object node that represents an input or output of the action (noted by small square attached to the boundary of action). Pin can optionally have arrows to represent input vs output. Not that the following is very same model as above (6.5 == 6.4). Pins mean exactly the same as object nodes.
A pin with zero multiplicity means it can be optional pin (both for input and output). SysML requires <<optional>> stereotype written to these types of pins.
Activity parameter = specialized kind of object node, that is attached to the frame of activity diagram to represent input or output to the activity as a whole. The name string format is the same as object node. Like a pin, parameters can have lower multiplicity of zero (making it an optional parameter) but it must have stereotype of <<operational>>.
Nonstreaming behavior = actions and activities where object tokens are consumed or generated only at the moment that action begins or completes execution. Thus any actions that follow this action must wait until this action completes.
Streaming behavior = input and outputs are consumed and generated even while action is still executing.
Edges
Activities can contain two general kinds of elements:
– Nodes (actions and object nodes) covered in sections above
– Edges (object flow and control flow) covered below
Object flow = edge that transports object tokens, notated with solid line with an open arrowhead. Shows flow from one node to another during activity execution (the 7 arrow lines below). The object token produced at the tail end of first node must be acceptable as input by the arrowhead end node – this can be ensured by having identical types or having the upstream type be a supertype of the downstream type (subtype)
The example figure on right shows that in the BDD, the transfer command is a subtype of command, and therefore can inherit the transfer command in the activity diagram (generalization). This is powerful for extensibility as the design has become more abstracted.
Control flow = edge that transports control tokens, used to convey sequencing constraints among a set of actions. There are two notations for control flows – a dashed line with open arrowhead or a solid line with open arrowhead. (though dash line is recommended so it distinguishes from object flows)
Example above shows four action nodes, of which two are behavior actions (fire thrusters), one is wait time (at) and one is accept event action (orbit radius updated).
Actions
There are three conditions for starting an action:
– Activity that owns action is currently executing
– Control token arrives on each of incoming control flows
– Sufficient number of object tokens arrive to satisfy the lower multiplicity of input pin
In example above, the ma action has one two incoming edges, one control and one object flow. Object flow is multiplicity of zero mean it is not needed to start the action if a control token arrives. But it must of have at least 1 control token in order to start the action (by default its one)
The vc action is similar but neither input edges have multiplicities, meaning both are necessary in order to start this action.
The rs action has single optional object flow, which means this action will execute whenever the owning activity begins to execute. This would be the same for any action node that has no input edges.
Note that input edges always represent an AND condition, not OR.
There are four types of actions:
– Call behavior actions
– Send signal actions
– Accept event actions
– Wait time actions
Call Behavior Actions = specialized action that invokes another behavior when enabled, which can be any of 3 kinds – an interaction, a state machine or another activity (letting you decompose a higher level behavior into a set of lower level ones). In figure 6.13, all three are call behavior actions where if rake symbol appears in lower right, it indicates that the behavior being called is an activity. For rs, it is ambiguous as it could be calling could be interaction or state machine (though rare to call state machine).
When a call behavior action invokes another activity, the pins must match the activity parameters of the activity called.
In this example, there are 3 calls to the same behavior “Create virtual channel frame” based on 3 similar actions.
Send Signal Actions = a specialized kind of action that asynchronously generates and sends a signal instance when enabled, noted with arrow like rectangle. The signal instance is sent is to a signal that is defined somewhere else in the model hierarchy. Example below shows the activity action calling a signal that is defined in BDD elsewhere.
Accept Event actions = partners with the send signal action and accepts the event action, noted with concave rectangle.
This figure shows asynchronous communication between two distinct system behaviros (one measuring altitude and one firing the thrusters). If the fire thrusters part is executing first but has no orbit signal received, it simply waits for it until the signal is present.
If the accept event action as no input edges, it is constantly running. The difference between that and Figure 6.17 is that the accept event action with no input edge will continue to run after execution (signal received), whereas 6.17 it stops running until next Fire Thrusters action fires.
Wait time actions = waits for a time event to occur, noted by an hourglass symbol, with expression below it explaining what time its waiting for. This is a special type of accept event action (based on time).
The time expression below the node can be absolute time or relative time.
Absolute time = begins with keyword “at”
Relative time = begins with keyword “after”
If the wait time action is relative to time to wait (like after 50 seconds), this timer starts as soon as the activity begins executing. After completion of the action, it will wait another 50 seconds and start again. As long as the activity is running, this action can fire multiple times.
Control Nodes
Control nodes = steer the execution of an activity along different paths, redirect flow of control / object tokens. There are seven types:
– Initial nodes
– Activity final nodes
– Flow final nodes
– Decision nodes
– Merge nodes
– Fork nodes
– Join nodes
Initial node = marks the starting point of an activity, noted by a small filled in circle and has a exactly one outgoing flow. Though not always necessary, depending on situation. Following example has initial node going into a fork node.
Flow final nodes = control nodes that mark the end of the flow of control token (thereby destroyed) and marked with circle containing an X (in example below, this happens after orbit radius updated, the activity itself is not terminated though, just the instance of that control token). Can have more than one flow final nodes.
Activity final nodes = control node that terminates all flows of control, and ends the whole activity – marked with circle containing a smaller filled circle within (in example below, the whole Execute Hohmann Transfer activity is terminated at the last fire thrusters). Can have more than one activity final nodes.
Decision Nodes = marks the start of alternative sequences in an activity, noted by a hollow diamond. Decision node must have a single incoming edge and generally two or more outgoing edges (usually a Boolean expression called guard). This expression is evaluated against the incoming object or control token and the forwarded down the matching path.
Merge nodes = marks the end of an alternative sequence in activity and is noted the same as a decision node (a hallow diamond). It is the opposite of decision edge in that it has one or more incoming edges and only a single outgoing edge. Any tokens incoming are automatically forwarded to the outgoing edge. These are often used with decision nodes for looping.
Merge nodes also used for showing multiple path interleaving of tokens, as the figure 6.23 below. Here an output of single stream of objects tokens of type Transfer Frame are created.
Fork Nodes = marks the start of concurrent sequences in an activity, noted by a single line segment (in any direction) and must have a single incoming edge and two or more outgoing edges. Whatever token is incoming (object or control token), it is duplicated to all outgoing edges and independent of each other. All concurrent paths should not depend on each other and disregard which ones complete first.
In the example below, ma will execute immediately after the fork whereas the vc will still wait for a transfer command object token is received.
Join nodes = opposite of fork node where one or more incoming edges and a single outgoing edge. Difference between this and merge node is that join node requires all concurrent incoming edges to be present before moving forward to the next node.
Activity Partitions
Activity partitions = way to show the actions within activity and the structure that performs that action, noted by a large rectangle with a header specifying the partition. Activity partitions can be vertical or horizontal. Usually the activity partition represents a block or party property somewhere else in the system model, conveying that actions in that partition are allocated to the named structure.